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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version S.x.y 

where: 

8 indicates release 1999. 

X the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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Scope 



The requirements described in the present document are mandatory for implementation in all GSM MSs and BSSs 
capable of supporting the Adaptive Multi-Rate speech traffic channel, unless otherwise stated. 

Unless otherwise specified, references to GSM include GSM at any frequency band. 

1.1 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 44.018: "Mobile radio interface layer 3 specification. Radio Resource Control Protocol". 

[3] 3GPP TS 45.002: "Multiplexing and multiple access on the radio path". 

[4] 3GPP TS 45.003: "Channel Coding". 

[5] 3GPP TS 45.005: "Radio transmission and reception". 

[6] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC - BSS) 

interface. Layer 3 specification". 

[7] 3GPP TS 28.062: "Inband Tandem Free Operation (TFO) of Speech Codecs". 

1 .2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. Further GSM related abbreviations are 
listed in 3GPPTR 21.905. 

AMR Adaptive Multi-Rate 

AMR-WB Adaptive Multi-Rate Wideband 

ACS Active Codec Set 

CMC Codec Mode Command 

CMI Codec Mode Indication 

CMR Codec Mode Request 

ICM Initial Codec Mode 

RATSCCH Robust AMR Traffic Synchronized Control Channel 



General 



The present document gives the detailed requirements for the correct operation of in call service specific link adaptation 
and control for GSM services implemented in GSM Mobile Stations (MS)s and Base Station Systems (BSS)s. 

In this specification the term AMR refers to both narrow-band and wide-band AMR codecs if not otherwise stated. 

For the Adaptive Multi-Rate (AMR) speech service, the detailed description and requirements for the associated inband 
signaling, AMR codec mode adaptation, and AMR codec configuration are given. 
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An inband signalling channel is defined for AMR which enables the MS and the BTS to exchange messages on applied 
or requested speech and channel codec modes. Codec mode adaptation for AMR is based on received channel quality 
estimation in both MS and BTS, followed by a decision on the most appropriate speech and channel codec mode to 
apply at a given time. 

The overall operation of AMR, in terms of used codec modes as well as general adaptation behaviour is controlled by 
the network. 



3 Adaptive Multi-Rate inband control and link 

adaptation 

3.1 General operation 

3.1 .1 Operation without Tandem Free Operation 

A high-level block diagram of the complete AMR system is depicted in figure 1. The system consists of the major 
components TRAU and BTS on the network side and the MS. On the network side, speech encoder (SPE) and channel 
encoder (CHE) as well as channel decoder (CHD) and speech decoder (SPD) are connected via the serial A-bis 
interface. For each link, quality information is derived by estimating the current channel state. Based on the channel 
state, and also taking into consideration possible constraints from network control, the codec mode control, which is 
located on the network side, selects the codec modes to be applied. 

The channel mode to use (TCH/AFS, TCH/AHS, O-TCH/AHS, TCHAVFS, O-TCH/WFS or O-TCHAVHS) is 
controlled by the network. Uplink and downlink always apply the same channel mode. 

For codec mode adaptation the receiving side performs link quality measurements of the incoming link. The 
measurements are processed yielding a Quality Indicator. For uplink adaptation, the Quality Indicator is directly fed 
into the UL mode control unit. This unit compares the Quality Indicator with certain thresholds and generates, also 
considering possible constraints from network control, a Codec Mode Command indicating the codec mode to be used 
on the uplink. The Codec Mode Command is then transmitted inband to the mobile side where the incoming speech 
signal is encoded in the corresponding codec mode. For downlink adaptation, the DL Mode Request Generator within 
the mobile compares the DL Quality indicator with certain thresholds and generates a Codec Mode Request indicating 
the preferred codec mode for the downlink. The Codec Mode Request is transmitted inband to the network side where it 
is fed into the DL Mode Control unit. This unit generally grants the requested mode. However, considering possible 
constraints from network control, it may also override the request. The resulting codec mode is then applied for 
encoding of the incoming speech signal in downlink direction. Both for uplink and downlink, the presently applied 
codec mode is transmitted inband as Codec Mode Indication together with the coded speech data. At the decoder, the 
Codec Mode Indication is decoded and applied for decoding of the received speech data. 
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Figure 1 : High level AMR block diagram 

Codec mode selection is done from a set of codec modes (ACS, Active Codec Set), which may include 1 to 4 AMR 
codec modes. Associated with this set is a list of 1 to 3 switching thresholds and hysteresis used by the DL Mode 
Request Generator and the UL mode control unit to generate the Codec Mode Requests and Codec Mode Commands. 
These configuration parameters (ACS, thresholds, hysteresis) are defined at call set-up and can be modified at handover 
or during a call. 

3.1 .2 Operation with ongoing Tandem Free Operation 

If tandem free operation is ongoing (see 3GPP TS 28.062) then the speech signal has to be transmitted over two radio 
links, first uplink (MSI to BTSl) and then downlink (BTS2 to MS2), respectively symmetrically in the reverse 
direction. The optimal Codec Mode in direction MS 1 to MS2 shall be derived from the Codec Mode Command for the 
first uplink (CMCl, within BTSl) and the Codec Mode Request derived for the second downlink (CMR2 within MS2) 
in the following way: MS2 shall send the CMR2 back to BTS2 in the usual way. BTS2 shall either accept this CMR2 
(default) or may modify it according to network control needs: CMR2'. Then BTS2 shall send the CMR2' further 
upHnk to its TRAU2, to TRAUl and downhnk to BTSl (see 3GPP TS 28.062 on how this transmission shall be handled 
on Abis and A interfaces). BTSl combines the received CMR2' with its own derived CMCl by taking the minimum of 
both values. If needed, BTS 1 may modify this minimum value according to own network control (— > CMCl ") and 
shall send it finally downlink to MSI as CMC. The identical procedure shall be performed in the reverse direction. 
Annex C gives an informative description. 

3.1 .3 Operation at Inandover witin ongoing Tandem Free Operation 

Before and during an handover at one or both sides of the MS-to-MS connection, it may be needed to freeze the codec 
mode adaptation for a short while, e.g. to optimise the common Active Codec Set, or to allow fast (re-)synchronisation 
between BTS and TRAU or to optimise the CMI Phase in downlink. Both BTSs may therefore enable or disable the 
codec mode adaptation (see 3GPP TS 28.062). As long as the codec mode adaptation is frozen to a specific codec mode, 
then this codec mode shall be used in both directions as long as tandem free operation is ongoing, or tandem free 
operation shall be discontinued. The Codec Mode Requests from the MSs may be taken into account to decide whether 
to continue TFO or not, but not for codec mode adaptation. 



3.2 Inband Signalling 



The AMR inband signalling consists of two parts: 

Frequent signalling, used for Codec Mode Indication and Codec Mode Command/Request. 

Robust, less frequent signalling, based on frame stealing, used for changing the AMR configuration 
(RATSCCH). 
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3.2.1 Frequent inband signalling for AMR codec mode adaptation 

3.2.1.1 General aspects 

The codec mode information, which has to be transmitted on each link, consists of Codec Mode Indications and Codec 
Mode Commands in the downhnk, respectively Codec Mode Indications and Codec Mode Requests in the uplink. 
Codec Mode Indications inform the receiver about the currently applied codec mode. Codec Mode Commands inform 
the other end about the codec mode to be applied on the other link. Codec Mode Requests inform the other end about 
the preferred codec mode on the other link. 

Codec mode information is transmitted inband in the speech traffic channel, using a part of its transmission capacity. 
The coding of codec modes in the inband signalling is given in subclause 3.4.1. Channel coding of codec mode 
information is specified in 3GPP TS 45.003 [4] for all frame types. 

Codec modes are constrained to change only every second speech frame. Codec Mode Commands/Requests and Codec 
Mode Indications are sub-sampled such that they occur only every second frame. Codec Mode Indications and Codec 
Mode Commands/Requests shall be transmitted alternating within consecutive speech frames. 

Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together within every 
RATSCCH frame. 

3.2.1 .2 Operation with DTX enabled 

For SID_FIRST frames, the Codec Mode Indication or Codec Mode Command/Request in phase with the alternating 
transmission shall be transmitted (same phase as in speech frames). 

Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together in every 
SID_UPDATE frame (as in RATSCCH frames). 

For ONSET frames the Codec Mode Indication for the subsequent speech frame shall be transmitted, regardless of the 
phase of the inband signalling. The general phase of the inband signalling shall not be changed by that. 

3.2.1 .3 Transmitter/Receiver Synchronisation 

The alternating transmission of the codec mode information requires synchronisation of transmitting and receiving ends, 
such that Codec Mode Indications and Codec Mode Commands/Requests are decoded in correct order. To ensure 
proper synchronisation, the codec mode information shall be transmitted aligned to the 26-multiframe structure of the 
GSM system. 

For TCH/AFS and TCH/WFS associated with a training sequence in TSC Set 1, and for TCH/AFS and TCH/WFS 
associated with a training sequence in TSC Set 2 and assigned to an MS which indicates support for VAMOS I (see 
3GPP TS 24.008), and for O-TCHAVFS, the default transmission phase shall be such that Codec Mode Indications are 
sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) in the uplink and TDMA 
frames 4, 13, 21 (modulo 26) in the downlink as defined in 3GPP TS 45.002 [3]. For TCH/AFS and TCH/WFS 
associated with a training sequence in TSC Set 2 and assigned to an MS which indicates support for VAMOS II (see 
3GPP TS 24.008), the default transmission phase shall be such that Codec Mode Indications are sent with speech 
frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) in the uplink and TDMA frames 4, 12, 21 
(modulo 26) in the downlink as defined in 3GPP TS 45.002 [3]. For TCH/AHS associated with a training sequence in 
TSC Set 1, and for TCH/AHS associated with a training sequence in TSC Set 2 and assigned to an MS which indicates 
support for VAMOS I (see 3GPP 24.008), and for O-TCH/AHS and O-TCH/WHS, the default transmission phase shall 
be such that Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 
(modulo 26) or 1, 9, 18 (modulo 26) depending on the subchannel in the uplink and TDMA frames 4, 13, 21 (modulo 
26) or 5, 14, 22 (modulo 26) depending on the subchannel, in the downlink, as defined in 3GPP TS 45.002 [3]. For 
TCH/AHS associated with a training sequence in TSC Set 2 and assigned to an MS which indicates support for 
VAMOS II (see 3GPP 24.008), the default transmission phase shall be such that Mode Indications are sent with speech 
frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) or 1, 9, 18 (modulo 26) depending on the 
subchannel in the uplink and TDMA frames 4, 12, 21 (modulo 26) or 5, 14, 22 (modulo 26) depending on the 
subchannel, in the downlink, as defined in 3GPP TS 45.002 [3]. 

This default phase of the Codec Mode Indication in downlink direction is called "odd", the alternative phase, one speech 
frame shifted, is called "even". The phase in uplink is always the same and is never changed. 
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At call set-up, after a channel mode modify with consistent MultiRate configuration IE and after each reallocation of the 
circuit switched channel, the default phase (odd) shall be used in downlink direction. During a call, the phase of Codec 
Mode Indication may be changed in downlink by using a RATSCCH message. In case of reallocation failure and fall 
back to the channel before the reallocation attempt, the phase before the channel reallocation attempt shall be used again 
(except if a RATSCCH procedure is pending, see section 3.2.2.2 bullet 6). 

3.2.2 Robust inband signalling for AMR configuration modification 

3.2.2.1 General aspects 

The RATSCCH mechanism may be used in case of Tandem Free Operation to modify the AMR Configuration on the 
radio interface without interruption of the speech transmission. Its application for TFO is described in 3GPP TS 28.062. 
This recommendation defines the RATSCCH protocol and the RATSCCH messages. The channel coding is defined in 
3GPP TS 45.003 and the receiver performance in 3GPP TS 45.005. RATSCCH handling is mandatory for MS and 
optional for BTS. 

RATSCCH is based on frame stealing. On TCH/AFS, TCH/WFS and O-TCH/WFS, one speech frame is stolen for each 
RATSCCH message, and on TCH/AHS, O-TCH/AHS and O-TCH/WHS two speech frames are stolen. In TCH/AHS 
and O-TCH/AHS RATSCCH is mapped onto two consecutive speech frames, the RATSCCH_MARKER and the 
RATSCCH_DATA. Both shall be sent always as one pair. 

FACCH frames have higher priority than RATSCCH frames. If FACCH and RATSCCH are scheduled for 
transmission for the same speech frame, then the FACCH shall be sent first, followed by the RATSCCH. If the 
RATSCCH is delayed due to FACCH, then the appropriate counters shall also be started as per section 3.2.2.2, based on 
actual transmission of the RATSCCH on the radio interface. If in the case of TCH/AHS, O-TCH/AHS and O- 
TCH/WHS, FACCH steals the second frame of one RATSCCH message (RATSCCH_DATA), the complete 
RATSCCH message (RATSCCH_MARKER and RATSCCH_DATA) shall be sent following the FACCH frame. 

3.2.2.2 RATSCCH protocol 

The RATSCCH protocol elements consist of a number of REQuest Messages and three ACKnowledgement Messages. 
One information exchange consists typically of one REQ-ACK cycle between the "Initiator" and the "Addressee". 
While the Initiator is waiting for an ACK, it shall not send any new REQ message, i.e. transmission and 
acknowledgement of one REQ-ACK cycle shall be completed before the next cycle is started. ACK messages, as 
reaction to received REQ messages, shall always be sent back as soon as possible, and latest within 3 speech frames. 
Both sides shall continuously monitor the radio reception for the RATSCCH pattern and decode the RATSCCH 
message. 

The typical REQ-ACK cycle is defined as: 

1) If one side ("Initiator") wants to initiate the information exchange, it shall send the desired REQ message. At the 
same time the Initiator shall start two counters: 

ACK_Timeout that shall count the elapsed speech frames occurrences (after REQ) in receive direction and 
REQ_Activation that shall count the elapsed speech frames occurrences (after REQ) in send direction. 

2) If the REQ message was decoded error-free (by CRC check, see 3GPP TS 45.003 [4]) and is defined (see section 
3.2.2.3) at receiver side ("Addressee"), then the Addressee shall send an ACK_OK message back. At the same 
time the Addressee shall start two own counters: 

REQ_Activation that shall count the elapsed speech frames occurrences after REQ in receive direction and 
ACK_Activation that shall count the elapsed speech frames occurrences after ACK in send direction. 

3) If the Initiator receives an ACK_OK, then it shall ignore its ACK_Timeout counter and shall start an 
ACK_Activation counter instead that shall count the elapsed speech frames after ACK_OK in receive direction. 

4) The contents of the REQ messages shall become valid in the direction from Initiator to Addressee exactly in that 
frame, where the REQ_Activation counters reach the value 12 and for all following frames. 

The contents of the REQ message shall become valid in the direction from Addressee to Initiator exactly in that 
frame, where the ACK_Activation counters reach the value 12 and for the following frames. 
Note: Due to the transmission delay and the reaction time within the Addressee (REQ to ACK) the activation 
takes place in general at four different points in time, but exactly synchronised and defined in both directions. 
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5) If another REQ message is received by the Adressee before REQ_Activation has elapsed, the Adressee shall 
ignore the message. 

6) If, following a L3 message (e.g. ASSIGNMENT COMMAND or HANDOVER COMMAND) the physical layer 
is disconnected and re-established on a new channel, any pending RATSCCH procedure shall be cancelled in the 
MS: the timers REQ_Activation and ACK_Activation are stopped and the configuration change required by the 
RATSCCH procedure is not performed. 

In the case the L3 procedure fails and the MS comes back to the original channel, any pending acknowledged 
REQ message shall be applied regardless the values of REQ_Activation and ACK_Activation. 

7) If a L3 message CHANNEL MODE MODIFY with consistent MultiRate IE is received (see 3GPP TS 44.018), 
any pending RATSCCH procedure shall be cancelled in the MS: the timers REQ_Activation and 
ACK_Activation are stopped and the configuration change required by the RATSCCH procedure is not 
performed. 

Note: a speech frame occurrence is the part of the multiframe that is used by a speech frame or that could have been 
used by a speech frame (e.g. in the case of speech frame stolen by FACCH or during silence periods when 
DTX is active). 

Error Handling: 

1) If the REQ message was decoded error-free (no CRC error), but the message is not defined at the Addressee 
side, then the Addressee shall send an ACK_UNKNOWN message back. No counters are needed in this case. 
The Initiator, when receiving this ACK_UNKNOWN message shall terminate the exchange for this type of REQ 
message. 

2) If the RATSCCH message was detected, but could not be decoded correctly (CRC failure), or its contents was 
not consistent, then the Addressee shall send an ACK_ERR message back. No counters are needed in this case. 

3) If the Initiator does not receive an ACK_OK or ACK_UNKNOWN before the ACK_Timeout counter reaches 
10, or it receives an ACK_ERR instead, then it shall initiate the exchange again by resending the REQ and 
starting the timers anew. 

4) If the Initiator has sent the REQ unsuccessfully for three times, the retransmission shall be stopped. 

5) If at either side an ACK_ERR or ACK_UNKNOWN is received although no corresponding REQ has been sent 
before, this ACK messages shall be ignored. 

If the BTS receives an ACK_OK although it has not sent a corresponding REQ before, then the BTS shall initiate the 
sending of the used AMR Configuration down to the MS. 

3.2.2.3 RATSCCH messages 

Each RATSCCH message consists of its RATSCCH message identifier and potentially message parameters. In total 35 
net bits are available for each message. They are numbered 34... in the message descriptions below, and correspond to 
d(34) ... d(0) in 3GPP TS 45.003. Three different ACKnowledgement message are defined. 

3.2.2.3.1 ACK_OK message 

The ACK_OK message serves as an acknowledgement that a RATSCCH REQ message has been detected, correctly 
decoded (no CRC error) and that it is defined for the Addressee. It defines the exact activation time in direction from 
Addressee to Initiator. Table 3.2.2.3.1 shows the definition of the ACK_OK. 

Table 3.2.2.3.1 : Definition of the ACK_OK message 



Bit 


34... 2 1 


Value 


0...001 
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3.2.2.3.2 



ACK_ERR message 



The ACK_ERR message serves as a negative acknowledgement that a RATSCCH REQ message has been detected, 
i.e. the RATSCCH pattern was detected, but either could not be decoded correctly (CRC error) or its content is not 
understandable by the addressee. Table 3.2.2.3.2 shows the definition of the ACK_ERR. 

Table 3.2.2.3.2: Definition of the ACK_ERR message 



Bit 


34... 2 1 


Value 


0... 01 



3.2.2.3.3 



ACK_UNKNOWN message 



The ACK_UNKNOWN message serves as an acknowledgement that a RATSCCH REQ message has been detected and 
correctly decoded, but was unknown to the Addressee. Table 3.2.2.3.3 shows the definition of the ACK_UNKNOWN. 

Table 3.2.2.3.3: Definition of the ACK_UNKNOWN message 



Bit 


34... 2 1 


Value 


0... 01 1 



ACKnowledge messages shall only be sent in response to a REQuest message. 

3.2.2.3.4 CMI_PHASE_REQ message 

The CMI_PHASE_REQ message may be sent by the BTS to change the phase of the Codec Mode Indication in 
downlink. CMI_PHASE_REQ has only parameter. Codec Mode Indication Phase (CMIP). Table 3.2.2.3.4a shows the 
format. 

Table 3.2.2.3.4a: Format of the CMI_PHASE_REQ message 



Bit 


34 ...21 





Value 


0... 1 


CMIP 



Assuming the CMI_PHASE_REQ message replaces DL speech frame A^ (frames A^-7 and A^ for TCH/AHS, O- 
TCH/AHS and 0-TCHAVHS), then the new phase shall be used starting with DL speech frame N+12. The CMI Phase 
in uplink shall not be affected. The new CMI phase in downlink shall be active until it is modified by a new 
CMI_PHASE_REQ or until a handover is successfully executed. 

Table 3.2.2.3.4b shows how Codec Mode Indications and Codec Mode Commands shall be transmitted in even and odd 
speech frames depending on the value of MIP. See section 3.2.1.3 for the definition of even and odd speech frames. 

Table 3.2.2.3.4b: Phase of Codec Mode Indication/Command in DL depending on CMIP 



Value of 
CMIP 


Information 

transmitted in 

even speech frames 


Information transmitted in 
odd speech frames 





Codec Mode Indication 


Codec Mode Command 


1 (default) 


Codec Mode Command 


Codec Mode Indication 
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3.2.2.3.5 



AMR_CONFIG_REQ message 



The AMR_CONFIG_REQ message may be sent by the BTS during a call to change the AMR configuration on the 
radio interface without interruption of the speech transmission. AMR_CONFIG_REQ contains several parameters: 
Active Codec Set (ACS), Initial Codec Mode (ICM), and a pair of threshold and hysteresis values (THRESH/ and 
HYST/). Table 3.2.2.3.5a shows the format. 

Table 3.2.2.3.5a: Main Format of the AMR_CONFIG_REQ message 



Bit 


34. ..32 


31 


30 


29 ...28 


27 ...20 


19... 16 


15 ... 10 


9 ...6 


5...0 


Value 


1 


1 


1 


ICM 


ACS 


HYST2 


THRESH2 


HYST1 


THRESH1 



The ACS and ICM parameters are coded in the same way as defined in 3GPP TS 44.018 [2]. 

All threshold and hysteresis parameters in the AMR_CONFIG_REQ are valid only for downlink direction. The coding 
of these parameters is given in section 3.4.2. 

If the ACS consists of n modes («=1,2,3), then only THRESHl . . .THRESHn-i and HYSTl . . .HYSTn-7 are defined. 
The remaining bits are reserved for future use and shall be set to " 1 " . 

If the ACS consists of four modes, then the complete set of thresholds/hysteresis can not be sent with this message. In 
that case, all THRESH/' and HYST/' fields are reserved for future use and shall be set to "1". Similar, if the BTS has no 
threshold and hysteresis parameters for the given configuration, then all THRESHj and HYSTj field bits shall be set to 
"1" to indicate that they are undefined. The THRESH_REQ message shall be used to transmit these parameters at a 
later point in time. As long as the MS has no defined threshold and hysteresis parameters it shall use the Initial Codec 
Mode for the Codec Mode Request. 

Alternatively, in case of four codec modes, the BTS may send the three threshold and hysteresis parameters as shown 
in table 3.2.2.3.5.b. The coding of HYSTc is given in section 3.4.2. All three hysteresis values (HYSTl/2/3) are in that 
case represented by one common HYSTc value (HYSTl = HYST2 = HYST3 = HYSTc). 

Table 3.2.2.3.5b: Alternative Format of the AMR_CONFIG_REQ message for four modes 



Bit 


34. ..32 


31 


30 


29 ... 28 


27 ... 20 


19... 18 


17 ... 12 


11 ...6 


5...0 


Value 


1 


1 


1 


ICM 


ACS 


HYSTc 


THRESH3 


THRESH2 


THRESHl 



In this way the ACS and the associated thresholds may be sent in one single message, allowing an immediate Codec 
Mode Request generation within the MS for the new configuration. If needed the hysteresis parameters may be 
modified in a later THRESH_REQ message. 

The normal completion of an AMR_CONFIG_REQ procedure is then: 

Assuming that the AMR_CONFIG_REQ message replaces DL speech frame A^ (speech frames N-1 and A^ for 
TCH/AHS, O-TCH/AHS and O-TCHAVHS), then the BTS and MS shall use the new ACS and ICM starting 
with DL speech frame N+12. This means that from that speech frame on. Mode Indications on the DL and DL 
Mode Requests on the UL shall be interpreted relative to the new ACS. 

Assuming that the ACK_OK to the AMR_CONFIG_REQ message replaces UL speech frame M (speech frames 
M-1 and M for TCH/AHS, O-TCH/AHS and O-TCH/WHS), then the BTS and MS shall use the new ACS and 
ICM starting with UL speech frame M+12. This means that from that speech frame on. Mode Indications on the 
UL and UL Mode Commands on the DL shall be interpreted relative to the new ACS. 

NOTE: During a short time in the transition period the configuration is different in uplink and downlink direction. 



3.2.2.3.6 



THRESH_REQ message 



The THRESH_REQ message may be sent by the BTS to change the thresholds in the DL Mode Request Generator. The 
THRESH_REQ message contains up to three pairs of threshold and hysteresis values (THRESH/ and HYSTy). Table 
3.2.2.3.6 shows the format. 
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Table 3.2.2.3.6: Format of the THRESH_REQ message 



Bit 


34.. .30 


29 ... 26 


25 ... 20 


19... 16 


15... 10 


9. ..6 


5...0 


Value 


00001 


HYST3 


THRESH3 


HYST2 


THRESH2 


HYST1 


THRESH1 



The coding of the THRESH/ and HYSTj values is given in section 3.4.2. If the ACS consists of n (n=l, 2,3,4) modes, 
only THRESH 1 . . .THRESHn-7 and HYSTl . . .HYST«-7 are defined. The remaining THRESH/ and HYST/ fields are 
reserved for future use and shall be set to "1". 

The normal completion of a THRESH_REQ procedure is then: 

Assuming that the THRESH_REQ message replaces DL speech frame A^ (speech frames A^-7 and A^ for 
TCH/AHS, O-TCH/AHS and O-TCHAVHS), then the MS shall use the new thresholds and hysteresis starting 
with measurements of DL speech frame N+12. 

3.3 Codec mode adaptation 

3.3.1 Channel quality measure 

Codec mode adaptation is based on a normalized, one-dimensional measure of the channel quality, called the Quality 
Indicator. For reference purposes, the Quality Indicator is defined as an equivalent carrier to interferer ratio, C/Inom- The 
reference channel conditions for the normalized Quality Indicator C/Inorm shall be Typical Urban 3 km/h with ideal 
frequency hopping at 900 MHz. The corresponding reference receiver performance is specified as the minimum 
performance requirement in 3GPP TS 45.005. The MS and BSSs shall continuously update the Quality Indicator 
estimates. 

The Quality Indicator may be derived from an estimate of the current carrier to interferer ratio, C/Z^,, , or an estimate of 
the current raw bit error rate (BERgsi)- A normalization factor >0 dB may be applied between the estimate {C/Iest or 
BEResi) and the Quality Indicator to compensate for higher receiver performance than the minimum performance 
requirement in 3GPP TS 45.005. This normalization factor may be dependent on the C/I at the antenna connector. 

The MS shall apply a second normalization factor be applied to normalize the estimate with respect to different channel 
types, such that, with given C/I„orm and given codec mode, the FER after channel decoding becomes independent of the 
channel type. 

An example of channel quality measuring for the case of an Ideal Frequency Hopping channel in a Typical Urban 
Environment is given in Annex A. 

3.3.2 Generation of Codec Mode Commands and Requests 

For codec mode adaptation, the channel Quality Indicators are mapped to Codec Mode Commands/Requests, by 
quantizing the Quality Indicators. The output values of the quantizer shall represent the different codec modes. 

Hysteresis in the mapping from Quality Indicators to Codec Mode Commands/Requests should be used to prevent 
undesirable fast switching of CodecMode Commands/Requests. The hysteresis in the mapping is defined in the 
following way. The previously sent Codec Mode Command, CMC" (respectively Codec Mode Request, CMR") is used 
as the current state of the adaptation logic. For each state, lower and upper thresholds THR_MC_Dn(CMC") and 
THR_MC_Up(CMC") for the downlink, and THR_MR_Dn(CMR") and THR_MR_Up(CMR") for the uplink are 
defined. If the measure falls below the lower threshold, the next lower Codec Mode Command/Request 
commanding/requesting a more robust codec mode shall be generated. If the measure exceeds the upper threshold, then 
the next higher Codec Mode Command/Request commanding/requesting a less robust codec mode shall be issued. 
Otherwise, the previous Codec Mode Command/Request shall be repeated. 

The degree of hysteresis is controlled by appropriately setting the upper and lower decision thresholds. The thresholds 
shall be defined by layer 3 signalling, as described in subclause 3.4.2, or by RATSCCH messages. An example of 
decision thresholds for the case of an Ideal Frequency Hopping channel in a Typical Urban Environment is given in 
Annex B. 
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For reasons of channel error robustness of the codec mode information, the Codec Mode Commands/Requests and 
Codec Mode Indication shall be restricted to change at maximum to their nearest neighbours within the Active Codec 
Set. This means that mode switches to modes that are not direct neighbours to the previously transmitted mode shall be 
avoided. 

Nevertheless, the transitions may span more than one step in several situations : 

• after handover, (where the MS shall start with the Initial Codec Mode, regardless, which codec mode was used 
before) 

• when a distant MS has performed a handover while TFO is active 

when the AMR configuration is changed by an AMR_CONFIG_REQ message. 

3.3.3 Performance requirements 

3.3.3.1 MS response to the Codec Mode Command 

The MS shall after the reception of a Codec Mode Command apply the corresponding codec mode in uplink direction 
for the next possible speech frame and, and no more than three speech frames later. If the Codec Mode Command 
would require a change of the uplink codec mode by more than one step within the defined Active Codec Set, then the 
MS shall perform the transition from the currently used codec mode into the commanded codec mode in several steps, 
one step every second speech frame. Exceptions may occur only at call set-up and after handover, (where the MS shall 
start with the Initial Codec Mode, regardless, which codec mode was used before), and when the AMR configuration is 
modified with an AMR_CONFIG_REQ message. 

3.3.3.2 BTS response to the Codec Mode Request 

The BTS should apply the requested mode for the earliest possible speech frame, unless the BTS intends to override the 
Codec Mode Request from the MS due to network control needs. 

3.3.3.3 Performance of the Codec Mode Request Generation 

For TU3 channel conditions with ideal frequency hopping without DTX activated in GSM900 and GSM850, the MS 
shall produce Codec Mode Requests with the following accuracy: 

When a carrier to interferer ratio 4 dB higher than a defined upper threshold is applied to the antenna connector, 
the MS shall request a higher mode with a probability exceeding 90%. This shall be measured immediately after 
a settling-time of 200 ms. 

When a carrier to interferer ratio 4 dB lower than a defined lower threshold is applied to the antenna connector, 
the MS shall request a lower mode with a probability exceeding 90%. This shall be measured immediately after a 
settling-time of 200 ms. 

If required, the above test levels shall be reduced by the normalization factor defined in sub-clause 3.3.1 to account for 
potential improved receiver performances. 

For other frequency bands, the propagation profile should be adjusted to: TU1.5 for DCS1800 and PCS1900, TU6 for 
GSM400 and TU3.6 for GSM700. 

Note 1: Ideal frequency hopping assumes perfect decorrelation between bursts. For the propagation profile TU3, this 
is not easily achievable due to the high number of hopping frequencies required. Therefore, performance 
tests should be performed under ideal frequency hopping conditions for the following propagation 
profiles: TU50 for GSM900 and GSM850, TU25 for DCS1800 and PCS1900, TUlOO for GSM400, and 
TU60 for GSM700. 

Note 2: Receivers with improved performance may exceed the minimum requirements reflected by the 

normalisation factor defined in sub-clause 3.3.1. The normalisation factor, reflecting the improved 
performance, may depend on the carrier to interference ratio (C/I). Therefore, the conformance test of 
these receivers may require normalisation factors to be provided for each nominal C/I of the test. 
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3.4 Setup procedures 

3.4.1 Definition of tine AMR Active Codec Set 

AMR codec mode adaptation is done within a set of up to four codec modes. The codec mode set (Active Codec Set) to 
be used by the BSS and the MS is defined during call set-up and/or handover by layer 3 signalling defined in 3GPP TS 
44.018 [2]. The Active Codec Set (ACS) can be changed during a call using a RATSCCH message. 

The following convention (see table 3.4.1) applies for the coding of the codec modes for the inband signalling 
(Codec Mode Indications, Codec Mode Commands/ Requests). 

Table 3.4.1 : Identification of the codec modes within the Active Codec Set 



Identifier 

C0DEC_M0DE_1 
C0DEC_M0DE_2 

C0DEC_M0DE_3 
CODEC MODE 4 



Legend 

Represents the lowest codec mode (lowest bit-rate) of the ACS 

Represents the second lowest mode, if the ACS includes more than one 

mode 

Represents the third lowest mode, if the ACS includes more than two modes 

Represents the highest mode, if the ACS includes four modes 



If less than four Codec Modes are defined in the ACS, the unused codec Mode Indications and Mode Commands/Mode 
Requests shall not be signalled. Unused codec modes shall not be detected by the inband signalling decoder. 

3.4.2 Definition of CocJec MocJe Commancj/Request decision tinreslnolds 

The Codec Mode Command/Request decision thresholds shall be defined at call set-up and/or handover by layer 3 
signalling as defined in 3GPP TS 44.018 [2]. The decision thresholds may be changed during a call using a RATSCCH 
message. The decision thresholds shall apply to the reference channel conditions TU3 ideal frequency hopping at 900 
MHz. For each pair of neighbouring codec modes in the Active Codec Set, a threshold and a hysteresis value in terms of 
normalized carrier to interference ratio (C/I„orm), is defined. The lower decision threshold for switching from mode j to 
mode j-1 is given by the signalled threshold. The threshold is referred to as THR_MC_Dn(j) or, THR_MR_Dn(j) in 
subclause 3.3.2. 

The sum of the signalled threshold and hysteresis constitutes the upper threshold between the codec modes, referred to 
as THR_MC_Up(j-l) or, THR_MR_Up(j-l). The figure below illustrates the definition of the decision thresholds, and 
the operational range of the Codec Modes. 



CODEC MODE 4 



CODEC MODE 3 



CODEC MODE 2 



CODEC MODE 1 



C/l 



THR_3 + HYST_3 = THR_MX_Up(3) 
THR_3 =THR_MX_Dn(4) 

THR_2 + HYST_2 = THR_MX_Up(2) 
THR_2 =THR_MX_Dn(3) 

THR_1 + HYST_1 =THR_MX_Up(1) 
THR_1 =THR_MX_Dn(2) 



Figure 2: Definition of Threshold and Hysteresis for codec mode adaptation 

The switching thresholds shall be given by the network in a consistent order, i.e. such that: 

- THR_1 < THR_2 < THR_3, and 

- THR_1 + HYST_1 < THR_2 + HYST_2 < THR_3 + HYST_3. 
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Parameter name 


Description 


Range 


Bits 


THR_1/2/3 


Lower thresholds for switching between mode j and j- 
1 


0-63 


6 


HYST_1/2/3 


Hysteresis values to obtain the higher thresholds for 
switching between mode j and j+1 


0-15 


4 



A threshold (THR) is given as an absolute value in 0.5 dB steps. The THR values between and 63 shall be mapped to 
normalized C/I values as follows: 



THR 1/2/3 
THR 1/2/3 
THR 1/2/3 



0.0 dB 
0.5 dB 
1.0 dB 



THR 1/2/3 
THR 1/2/3 



62 
63 



31.0 dB 
31.5 dB 



NOTE: The threshold for codec mode j should be set to such a normalized C/I value that codec mode j starts to 
degrade and that a PER of less than 1 % is observed. 

When using the RATSCCH format defined by table 3.2.2.3.5a or table 3.2.2.3.6 or when using layer 3 signalling for the 
definition of the threshold and hysteresis parameters, the HYSTl/2/3 shall be coded in 0,5 dB steps as follows: 



HYST 1/2/3 

HYSTl/2/3 1 

HYSTl/2/3 2 



0.0 dB 
0.5 dB 
1.0 dB 



HYSTl/2/3 
HYSTl/2/3 



14 
15 



7.0 dB 
7.5 dB 



When using the RATSCCH format defined by table 3.2.2.3.5b for the definition of the threshold and hysteresis 
parameters, HYSTC shall be coded in 1 dB steps as follows: 



HYSTc 





= 


1.0 dB 


HYSTc 


1 


= 


2.0 dB 


HYSTc 


2 


= 


3.0 dB 


HYSTc 


3 


= 


4.0 dB 



3.4.3 Initial Codec Mode Selection at Call Setup and Handover 

The Initial Codec Mode (ICM), to start the speech coding operation with at call set-up and after handover may be 
signalled by layer 3 signalling. It may also be signalled by a RATSCCH message. This explicitly signalled ICM shall 
have preference over the default ICM, as describe below: 

If the Initial Codec Mode is not signalled, then the default Initial Codec Mode is given by the following implicit rule. If 
the Active Codec Set contains: 

1 mode, then this hall be the Initial Codec Mode; 

2 or 3 modes, then the Initial Codec mode shall be the most robust mode of the set (with lowest bit rate); 

4 modes, then the Initial Codec Mode shall be the second most robust mode of the set (with second lowest 

bit rate. If the Active Codec Set is changed during the call, then this default Initial Codec Mode 
shall used until an other ICM is explicitly signalled. 
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Annex A (informative): 

Example Solution for Link quality estimation 

Link adaptation is based on a normalized measure C/Inom of the carrier to interferer ratio. This measure is composed of 
an estimate of the actual carrier to interferer ratio C/Igst (or equivalently the actual C/N). For ideal FH-hopping channels 
in a typical urban environment no further adjustment or normalization is required, as described in section 3.3.1. 

C/I estimates are derived by taking C and I measurements burst by burst from the equaliser algorithm. Intermediate 
processing results of the equaliser are estimates of the 'useful' received signal and the received noise or interference 
signal. Taking the ratio of the energies of both signals gives a C/I estimate for the present burst. 

The further processing of the burst- wise C/I estimates is as follows: 

The C/I estimates are converted to dB. 

Then FIR filtering is done with non-adaptive filters of order 100 for FR and 50 for HR channels (Filter 
coefficients are given in Table 1 and Table 2, which is read left to right line by line). The purpose of the filter is 
smoothing and prediction such that the filter output is an estimate of the expected C/I at the time instant for 
which the link adaptation operation, i.e. the codec mode selection, becomes effective. 

Table 1 : Filter coefficients of C/I measuring filter for TCH/AFS, TCH/WFS, and 0-TCH/WFS 



0.02737 


0.02692 


0.02643 


0.02573 


0.02527 


0.02499 


0.02448 


0.02393 


0.02335 


0.02286 


0.02240 


0.02203 


0.02158 


0.02106 


0.02072 


0.02032 


0.01993 


0.01956 


0.01923 


0.01877 


0.01825 


0.01782 


0.01743 


0.01715 


0.01682 


0.01642 


0.01614 


0.01566 


0.01520 


0.01489 


0.01465 


0.01422 


0.01382 


0.01340 


0.01303 


0.01273 


0.01236 


0.01205 


0.01178 


0.01141 


0.01102 


0.01068 


0.01031 


0.00998 


0.00958 


0.00928 


0.00909 


0.00882 


0.00854 


0.00827 


0.00800 


0.00784 


0.00757 


0.00729 


0.00693 


0.00659 


0.00629 


0.00601 


0.00586 


0.00565 


0.00540 


0.00510 


0.00491 


0.00473 


0.00464 


0.00443 


0.00424 


0.00397 


0.00385 


0.00360 


0.00351 


0.00311 


0.00290 


0.00269 


0.00232 


0.00204 


0.00180 


0.00165 


0.00137 


0.00119 


0.00098 


0.00073 


0.00052 


0.00031 


0.00006 


-0.00018 


-0.00027 


-0.00034 


-0.00043 


-0.00064 


-0.00079 


-0.00104 


-0.00107 


-0.00122 


-0.00146 


-0.00162 


-0.00183 


-0.00195 


-0.00208 


-0.00232 


-0.00253 





















Table 2: Filter coefficients of C/I measuring filter for TCH/AHS, 0-TCH/AHS and 0-TCH/WHS 



0.03998 


0.03903 


0.03781 


0.03650 


0.03513 


0.03406 


0.03296 


0.03223 


0.03116 


0.03036 


0.02911 


0.02832 


0.02756 


0.02682 


0.02585 


0.02524 


0.02441 


0.02368 


0.02277 


0.02194 


0.02118 


0.02032 


0.01923 


0.01837 


0.01788 


0.01712 


0.01636 


0.01544 


0.01474 


0.01431 


0.01370 


0.01297 


0.01263 


0.01221 


0.01181 


0.01135 


0.01080 


0.00974 


0.00919 


0.00836 


0.00790 


0.00748 


0.00681 


0.00647 


0.00613 


0.00558 


0.00534 


0.00494 


0.00436 


0.00403 


0.00351 
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Annex B (informative): 

Example Definition of IVIode Command/Request decision 

thresholds 

Following Table 3 gives an example definition of Mode Command/Request decision thresholds for the TCH/AFS traffic 
channel employing a codec mode set which contains the 12.2 kbit/s, the 7.95 kbit/s, and the 5.9 kbit/s codec modes. 
Table 4 gives an example definition of Mode Command/Request decision thresholds for the TCH/AHS traffic channel 
employing a codec mode set which contains the 7.95 kbit/s, the 6.7 kbit/s, the 5.9 kbit/s, and the 5.15 kbit/s codec 
modes. Table 5 gives an example definition of Mode Command/Request decision thresholds for the TCH/WFS traffic 
channel employing a codec mode set which contains the 12.65 kbit/s, the 8.85 kbit/s, and the 6.60 kbit/s codec modes. 
Table 6 gives an example definition of Mode Command/Request decision thresholds for the O-TCH/AHS traffic 
channel employing a codec mode set which contains the [tbd] kbit/s, the [tbd] kbit/s, the [tbd] kbit/s, and the [tbd] kbit/s 
codec modes. Table 7 gives an example definition of Mode Command/Request decision thresholds for the 0-TCH/WFS 
traffic channel employing a codec mode set which contains the 23.85 kbit/s, the 15.85 kbit/s, the 12.65 kbit/s, and the 
6.60 kbit/s codec modes. Table 8 gives an example definition of Mode Command/Request decision thresholds for the 
O-TCH/WHS traffic channel employing a codec mode set which contains the 12.65 kbit/s, the 8.8kbit/s, and the 6.60 
kbit/s codec modes. 

Table 3: MC/MR decision thresholds for TCH/AFS 



MC"/MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


12.2 kbit/s 


11.5dB 


+ oo 


7.95 kbit/s 


6.5 dB 


13.5 dB 


5.9 kbit/s 


— oo 


8.5 dB 



Table 4: MC/MR decision thresholds for TCH/AHS 



MC7MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


7.95 kbit/s 


15.0dB 


+ oo 


6.7 kbit/s 


12.5dB 


17.0 dB 


5.9 kbit/s 


II.OdB 


15.0 dB 


5.15 kbit/s 


— oo 


13.0 dB 



Table 5: MC/MR decision thresholds for TCH/WFS 



MC7MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


12.65 kbit/s 


lO.OdB 


+ oo 


8.85 kbit/s 


7.0 dB 


12.0 dB 


6.60 kbit/s 


-oo 


9.0 dB 



Table 6: MC/MR decision thresholds for O-TCH/AHS 



MC7MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


[tbd] kbit/s 


[tbd] dB 


+ oo 


[tbd] kbit/s 


[tbd] dB 


[tbd] dB 


[tbd] kbit/s 


[tbd] dB 


[tbd] dB 


[tbd] kbit/s 


— oo 


[tbd] dB 
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Table 7: MC/MR decision thresholds for 0-TCH/WFS 



MC7MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


23.85 kbit/s 


[tbd] dB 


+ oo 


15.85 kbit/s 


[tbd] dB 


[tbd] dB 


12.65 kbit/s 


[tbd] dB 


[tbd] dB 


6.6 kbit/s 


— oo 


[tbd] dB 



Table 8: IVIC/MR decision thresholds for 0-TCH/WHS 



MC7MR" 


THR MC Dn(MC")/ 
THR MR Dn(MR") 


THR MC Up(MC")/ 
THR MR Up(MR") 


12.65 kbit/s 


[tbd] dB 


+ oo 


8.85 kbit/s 


[tbd] dB 


[tbd] dB 


6.6 kbit/s 


-oo 


[tbd] dB 
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Annex C (informative): 

Principles for AIVIR codec mode adaptation with TFO 

This annex C describes the procedures that are used for the codec mode adaptation of an Adaptive Muhi-Rate (AMR) 
call over two radio links when Tandem Free Operation (TFO) is active between them. The mechanism to initiate TFO 
between AMR calls is described in 3GPP TS 28.062. It is considered as a prerequisite that a common Active Codec Set 
has been defined between the BSSs (by the TFO_Protocol) and that TFO is ongoing with the same Active Codec Set on 
each side. 

The codec mode used in one direction may be different from the one used in the other direction, but for one direction 
the same codec mode is used from one MS to the other MS. The codec mode adaptation is performed independently on 
each direction, but in one direction the codec mode adaptation is triggered by both radio interfaces. 

The principle for codec mode adaptation in ongoing TFO is always that the BTS controlling the MS takes the final 
decision to upgrade or downgrade its local uplink direction. This BTS sends the Codec Mode Command downlink. 

The Codec Mode Request for the local uplink direction is taken directly into account and the effective delay is not 
higher than in normal connections. 

The Codec Mode Request from the remote side in the remote downlink direction is also taken into account, but it 
becomes active with a reaction time increased by the round trip delay between both BTSs. 

Upgrading is possible only if both radio links in one direction (first uplink then downlink) are good enough. 

Downgrading is necessary already if one (or both) radio link is not good enough. 



C.1 Downgrading 



For an active AMR call without TFO, the codec mode is downgraded when the quality of the radio link decreases. In 
that case the codec bit rate is reduced so that more throughput is left on the radio interface to add protection. The 
principle when TFO is active is that as soon as one side detects the need to downgrade the codec rate, it informs the 
other side and the codec mode is immediately downgraded. There is no negotiation before downgrading. 



C.1.1 Uplink downgrading 



The following figure shows the uplink adaptation due to detection by the BTS 1 of a bad quality in the uplink from the 
MSI. In that case the round trip delay between BTSl and BTS2 has no impact, as the uplink codec adaptation is 
decided immediately by BTS 1 and performed by the MS 1 . 
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Figure C.1 .1 : Uplink Downgrading 



C.1.2 Downlink downgrading 



The following figure C. 1 .2 shows the downlink adaptation due to detection by the MS 1 of a bad quality of the downlink 
from the BTS 1 . The codec mode adaptation must be performed on the far end MS (MS2), where the source encoder is 
located. In that case the round trip delay before the downlink adaptation is effective has an high impact. If TFO would 
not be active, the round trip delay would be smaller, because the Codec Mode Request sent by the BTSl to the TRAUl 
would be immediately taken into account by the TRAUl and the new codec mode applied in downlink: without TFO 
ongoing the (tandem) source encoder is located in TRAUl. 
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Figure C.1.2: Downlink Downgrading 
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C.2 Upgrading 



When the radio quahty becomes better in one direction on both BSSs, then the signal on the radio interfaces needs less 
protection and consequently the useful speech information can be increased: the codec can be changed to a codec with a 
higher bit rate. The principle when TFO is active is that the decision to upgrade the codec is taken by the side that 
monitors the uplink quality. If a good quality has been detected in the uplink direction by this BTS2, then this BTS2 
upgrades the Codec Mode, if the Code Mode Request from the peer MS 1 allows that (when the downlink of the other 
side is also good). 



C.2.1 Downlink upgrading 



In the following figure, the downlink is monitored by MSI and the uplink by BTS2. 



TRAU1 TRAU2 

TFO estajblished with origina'lcodec 
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' T S 2 has 
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C M C : n 



M S 2 uses im m e d i^te ly 



Figure C.2.1 : Downlink Upgrading 

In that case the round trip delay from BTS 1 to BTS2 before the codec adaptation is effective in downlink to MS 1 has an 
high impact. The delay from the BTS2 to the MS2 before the codec adaptation is effective in uplink is small. The 
"effective" round trip delay may even be "indefinite" if either MSI or BTS2 is not able to upgrade its codec mode. 

In the figure above, if BTS2 had not measured a good uplink radio quality, then no adaptation would have been 
performed. The MS 1 respectively BTS 1 would go on sending continuously Codec Mode Request for the higher codec 
mode. 
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C.2.2 Uplink upgrading 

In the following figure, the downlink is monitored by BTS 2. 
MSI BTS1 
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uplink 'quality 
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CMI : new coded 
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Figure C.2.2: Uplink Upgrading 

The round trip delay before the codec adaptation is effective has a low impact, if the peer MS is able to upgrade its 
downlink codec mode. The round trip delay may even be indefinite if the peer MS is not able to upgrade its downlink 
codec mode. 

In the figure above, if MS2 had not measured a good downlink radio quality, then no adaptation would have been 
performed. 
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